home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 / Ham Radio 2000.iso / ham2000 / bbs / lzhuf / forward.doc < prev    next >
Text File  |  1993-12-11  |  17KB  |  442 lines
  1.  
  2.             FBB Forward Protocole.
  3.             ----------------------
  4.  
  5.             FBB software includes  two forward protocoles.  The first one
  6.        is standard with MBL/RLI protocole.  The second one was developped
  7.        to allow  a better  efficiency, particularly  on long  links where
  8.        propagation time  of data  are long.  The exchange  of commands is
  9.        reduced to a  minimum, and not  acknoledged to get  time. The data
  10.        transfer direction is changed every block of data, a block of data
  11.        holding up to  five messages.  This uses the  "pipeline" effect of
  12.        long links (Nodes and digipeaters),  and gain some time over short
  13.        links (HF...).
  14.  
  15.             FBB protocole is very simple in its principle. It is based on
  16.        MID/BID usage. The identification  is made by the  F letter in the
  17.        SID (system  type identifier  contained  in square  brackets). All
  18.        command lines must start in  first collumn with the 'F' character.
  19.        All command lines are ended by a return (CR) character.
  20.  
  21.             Suppose I  call  another BBS  to  forward some  mail.  When I
  22.        connect another BBS  using FBB  protocole, I will  receive the SID
  23.        followed by a text and the prompt (">"). If the SID contains the F
  24.        flag, I will send immediately my SID and the first proposal.
  25.  
  26.             Proposals looks like :
  27.  
  28.        FB P F6FBB FC1GHV FC1MVP 24657_F6FBB 1345
  29.        F>
  30.  
  31.        FB          : Identifies the type of the command (proposal)
  32.        P           : Type of message (P = Private, B = Bulletin).
  33.        F6FBB       : Sender (from field).
  34.        FC1GHV      : BBS of recipient (@field).
  35.        FC1MVP      : Recipient (to field).
  36.        24657_F6FBB : BID ou MID.
  37.        1345        : Size of message in bytes.
  38.        F>          :  End of proposal.
  39.  
  40.             ALL the fields are necessary.  This kind of command must hold
  41.        seven fields.  If  a field  is  missing upon  receiving,  an error
  42.        message will be send immediately followed by a disconnection.
  43.  
  44.             A proposal can  handle up  to five  FB command  lines. If the
  45.        total size of messages seems to be too important, the proposal can
  46.        handle less  lines. In  FBB  software, a  parameter is  defined in
  47.        INIT.SRV file to tell the maximum size of the message block. It is
  48.        set by default to 10KB  for VHF use. It can be  adjusted according
  49.        to the quality of the link.
  50.  
  51.        Exemple of proposal :
  52.  
  53.        FB P F6FBB FC1GHV.FFPC.FRA.EU FC1MVP 24657_F6FBB 1345
  54.        FB P FC1CDC F6ABJ F6AXV 24643_F6FBB 5346
  55.        FB B F6FBB FRA FBB 22_456_F6FBB 8548
  56.        F>
  57.  
  58.             This proposal is limited to three  FB lines, as the amount of
  59.        messages overran the 10KB limit defined for this link.
  60.  
  61.             When receiving  the  proposal,  the  other  BBS  will reject,
  62.        accept or defer the message. This command is made by a FS line :
  63.  
  64.        FS -+=
  65.  
  66.             This means :
  67.  
  68.             - I don't want the first message (-).
  69.             - I need the second message (+).
  70.             - I defer the third message, as I'm still receiving it.
  71.  
  72.             It should  interesting to  defer a  message if  you are still
  73.        receiving it on a other channel, or  if you think that the size is
  74.        to big,  or for  another  reason. The  message should  be proposed
  75.        again at the next connection.
  76.  
  77.             FS line  MUST  have  as  many +,-,=  signs  as  lines  in the
  78.        proposal.
  79.  
  80.             When  receiving  the  FS  lines,  I  can  send  the block  of
  81.        messages. Each message is  made with the title  on the first line,
  82.        the text, and  a Ctrl  Z in  the last line.  The is  no blank line
  83.        between the messages.
  84.  
  85.        Title of 2nd message
  86.        Text of 2nd message
  87.        .....
  88.        ^Z
  89.  
  90.             When the other  BBS has  received all the  asked messages, it
  91.        acknoledges by sending its proposal, and the system is reversed.
  92.  
  93.             If it has no message to send, it only sends a line :   
  94.  
  95.        FF
  96.  
  97.             This line must not to be followed by a F>.
  98.  
  99.             If the other hand has no message, it sends a line :
  100.  
  101.        FQ
  102.  
  103.             and asks for the disconnection.
  104.  
  105.  
  106.  
  107.  
  108.  
  109.        Example :
  110.        ---------
  111.  
  112.  
  113.        F6FBB                    FC1GHV
  114.        ----------------------------------------------------------------
  115.  
  116.        Connects FC1GHV
  117.  
  118.                                 Connected
  119.  
  120.                                 [FBB-5.11-FHM$]
  121.                                 Bienvenue a Poitiers, Jean-Paul.
  122.                                 >
  123.  
  124.        [FBB-5.11-FHM$]   (F6FBB has the F flag in the SID)
  125.        FB P F6FBB FC1GHV.FFPC.FRA.EU FC1MVP 24657_F6FBB 1345
  126.        FB P FC1CDC F6ABJ F6AXV 24643_F6FBB 5346
  127.        FB B F6FBB FRA FBB 22_456_F6FBB 8548
  128.        F>
  129.  
  130.                                 FS +-+  (accepts le 1st et le 3rd).
  131.  
  132.        Title 1st message
  133.        Text 1st message
  134.        ......
  135.        ^Z
  136.        Title 3rd message
  137.        Text 3rd message
  138.        ......
  139.        ^Z
  140.  
  141.                                 FB P FC1GHV F6FBB F6FBB 2734_FC1GHV 234
  142.                                 FB B FC1GHV F6FBB FC1CDC 2745_FC1GHV 3524
  143.                                 F>
  144.  
  145.        FS --  (Don't need them, and send immediately the proposal).
  146.        FB P FC1CDC F6ABJ F6AXV 24754_F6FBB 345
  147.        F>
  148.  
  149.                                 FS +  (Accepts the message)
  150.  
  151.        Title message
  152.        Text message
  153.        ......
  154.        ^Z
  155.  
  156.                                 FF  (no more message)
  157.  
  158.        FB B F6FBB TEST FRA 24654_F6FBB 145
  159.        F>
  160.  
  161.                                 FS +  (Accepts the message)
  162.  
  163.        Title message
  164.        Text message
  165.        ......
  166.        ^Z
  167.  
  168.                                 FF  (still no message)
  169.  
  170.        FQ  (No more message)
  171.  
  172.        Disconnection of the link.
  173.  
  174.  
  175.             In this example,  FBB protocole is  used as the  two BBS were
  176.        identified by the  F flag in  the SID.  If F6FBB had  sent the SID
  177.        [FBB-5.10-MH$] when answering FC1GHV,  the protocole should be the
  178.        standard MBL/RLI.
  179.  
  180.             All callsigns are only examples !
  181.  
  182.  
  183.  
  184.  
  185.        Extension to the protocole. Compressed forward FBB.
  186.        ---------------------------------------------------
  187.  
  188.        The protocole utilized for the  transfer of ascii files compressed
  189.        is an extension to the  existing protocole. The compressed forward
  190.        is  validated  by  the  presence  of  the  letter  B  in  the  SID
  191.        [FBB-5.12-BFHM$]. The transfer  of compressed files  can only take
  192.        place under FBB protocole. The presence of the letter B in the SID
  193.        without the F letter will remain without effect.
  194.  
  195.             The only difference as regard to the standard protocol is the
  196.        submit line.  It can  specify the  type of  data contained  in the
  197.        compressed message. FA  means that  the transfer will  be an ascii
  198.        compressed message.  FB means  that the  message will  be a binary
  199.        compressed file (this  last possibility is  not yet implemented).
  200.  
  201.        The submission of an ascii message will be in the form :
  202.        FA P FC1CDC F6ABJ F6AXV 24754_F6FBB 345
  203.  
  204.        The submission of a binary file will be in the form :
  205.        FB P FC1CDC F6ABJ F6AXV 24754_F6FBB 345
  206.  
  207.        The transfered data are of a specific format. The transfer will be
  208.        done in binary mode. This last one is derived of the YAPP protocol
  209.        which is very reliable. All transfer  is made of a header, a block
  210.        of data,  an  end of  message  and  a checksum.  Each  transfer is
  211.        equivalent to the transfer of one message of the standard protocol
  212.        and shall  not  be  followed  by  a control  Z,  the  end  of file
  213.        specifier is defined in another way.  Unlike YAPP transfers, there
  214.        is  no acknowledgement  during the  transmission of  messages, the
  215.        protocole is then more simple and efficient.
  216.  
  217.        Format of header for an ascii compressed message (submission FA) :
  218.  
  219.        <SOH>                    1 byte = 01 hex
  220.        Length of the header     1 byte = Length from the title,         
  221.                                      including the two <NUL> characters.
  222.        Title of the message     1 to 80 bytes
  223.        <NUL>                    1 byte = 00 hex
  224.        Offset                   1 to 6 bytes
  225.        <NUL>                    1 byte = 00 hex
  226.  
  227.  
  228.        Format of header for a binary compressed file (submission FB) :
  229.  
  230.        <SOH>                    1 byte = 01 hex
  231.        Length of the header     1 byte = Length from the filename,
  232.                                      including the two <NUL> characters.
  233.        Name of the file         1 to 80 bytes
  234.        <NUL>                    1 byte = 00 hex
  235.        Offset                   1 to 6 bytes
  236.        <NUL>                    1 byte = 00 hex
  237.  
  238.  
  239.        As to follow  the french regulation,  the title of  the message or
  240.        the file name are transmitted in readable ascii, not compressed.
  241.  
  242.        The offset is also  transmitted in ascii  and specifies the offset
  243.        at which the  data should be  inserted in  the file (in  case of a
  244.        fragmented file).  In  the  version 5.12,  this  parameter  is not
  245.        utilized and is always equal to zero.
  246.  
  247.        A data  block contains  from one  to 256  bytes. It begins  by two
  248.        bytes which specify the format.
  249.  
  250.        Data block format :
  251.  
  252.        <STX>                    1 byte = 02 hex
  253.        Number of data           1 byte = 00 to ff hex.
  254.                                 if length is 256 bytes, the value is 00.
  255.        Data bytes               1 to 256 bytes
  256.  
  257.  
  258.        The last data block  is followed by the  end of file specifier and
  259.        the checksum.
  260.  
  261.        End of file specifier format :
  262.  
  263.        <EOT>                    1 byte = 04 hex
  264.        Checksum                 1 byte = 00 to ff hex
  265.  
  266.        The checksum is  equal to  the sum  of all  the data  bytes of the
  267.        transmitted file, modulo 256 (8 bits) and then two's complemented.
  268.  
  269.        The checking of the checksum is very simple :
  270.  
  271.        The sum  of the  datas  from the  file  and the  checksum received
  272.        modulo 256 shall be equal to zero.
  273.  
  274.        In case of a checksum error, the  message or the file is not taken
  275.        to account and the system issues a disconnect request after having
  276.        sent the comment :
  277.  
  278.        *** Erreur checksum
  279.  
  280.  
  281.  
  282.        Ascii values of the characters (1 byte) used in the protocole :
  283.  
  284.        <NUL> = 00 hex
  285.        <SOH> = 01 hex
  286.        <STX> = 02 hex
  287.        <EOT> = 04 hex
  288.  
  289.        Most of  ideas for this  binary transmission  are issued from YAPP
  290.        protocole. Thanks to WA7MBL.
  291.  
  292.  
  293.  
  294.  
  295.  
  296.        Extension to the protocole. Compressed forward FBB Version 1.
  297.        -------------------------------------------------------------
  298.  
  299.        The protocole utilized for the  transfer of ascii files compressed
  300.        is an extension to the  existing protocole. The compressed forward
  301.        is  validated  by  the  presence  of  the  letters B1 in  the  SID
  302.        [FBB-5.15-B1FHLM$]. The transfer of compressed files may only take
  303.        place under FBB protocole. The presence of the letter B in the SID
  304.        without the F letter will remain without effect.
  305.  
  306.             The differences as regard to the binary protocol version are:
  307.  
  308.        - A variable number of fields in the submit line, but at least 7
  309.          (as in previous version).
  310.        - A new set of answers :
  311.          + or Y : Yes, message accepted
  312.          - or N : No,  message already received
  313.          = or L : Later, already receiving this message
  314.          H      : Message is accepted but will be held
  315.          R      : Message is rejected
  316.          E      : There is an error in the line
  317.          !Offset: Yes, message accepted from (Offset).
  318.  
  319.        Most of these answer do not need explanation or were already used
  320.        in previous version. + and Y, - and N, = and L are equivalent but
  321.        are still used for compatibility.
  322.  
  323.        !Offset asks the remote BBS to start transfer from Offset. 
  324.  
  325.        For instance, YL!3350RH (or +L!3350RH) means that :
  326.        - 1st message is accepted
  327.        - 2nd message is delayed
  328.        - 3rd message will be sent from offset 3350 (in compressed file)
  329.        - 4th message is refused
  330.        - 5th message is accepted but will be held
  331.  
  332.  
  333.        The submission of an ascii message will be in the form :
  334.        FA P FC1CDC F6ABJ F6AXV 24754_F6FBB 345
  335.  
  336.        The submission of a binary file will be in the form :
  337.        FB P FC1CDC F6ABJ F6AXV 24754_F6FBB 345
  338.  
  339.        The transfered data are of a specific format. The transfer will be
  340.        done in binary mode. This last one is derived of the YAPP protocol
  341.        which is very reliable. All transfer  is made of a header, a block
  342.        of data,  an  end of  message  and  a checksum.  Each  transfer is
  343.        equivalent to the transfer of one message of the standard protocol
  344.        and shall  not  be  followed  by  a control  Z,  the  end  of file
  345.        specifier is defined in another way.  Unlike YAPP transfers, there
  346.        is  no acknowledgement  during the  transmission of  messages, the
  347.        protocole is then more simple and efficient.
  348.  
  349.        Format of header for an ascii compressed message (submission FA) :
  350.  
  351.        <SOH>                    1 byte = 01 hex
  352.        Length of the header     1 byte = Length from the title,         
  353.                                      including the two <NUL> characters.
  354.        Title of the message     1 to 80 bytes
  355.        <NUL>                    1 byte = 00 hex
  356.        Offset                   1 to 6 bytes
  357.        <NUL>                    1 byte = 00 hex
  358.        data blocs ...
  359.  
  360.        Format of header for a binary compressed file (submission FB) :
  361.  
  362.        <SOH>                    1 byte = 01 hex
  363.        Length of the header     1 byte = Length from the filename,
  364.                                      including the two <NUL> characters.
  365.        Name of the file         1 to 80 bytes
  366.        <NUL>                    1 byte = 00 hex
  367.        Offset                   1 to 6 bytes
  368.        <NUL>                    1 byte = 00 hex
  369.        data blocs ...
  370.  
  371.        As to follow  the french regulation,  the title of  the message or
  372.        the file name are transmitted in readable ascii, not compressed.
  373.  
  374.        The offset is also  transmitted in ascii  and specifies the offset
  375.        in  the file from which the  data will be sent.
  376.  
  377.        A data  block contains  from one  to 256  bytes. It begins  by two
  378.        bytes which specify the format.
  379.  
  380.        Data block format :
  381.  
  382.        <STX>                    1 byte = 02 hex
  383.        Number of data           1 byte = 00 to ff hex.
  384.                                 if length is 256 bytes, the value is 00.
  385.        Data bytes               1 to 256 bytes
  386.  
  387.  
  388.        The first block data first contains the CRC16 of the full binary
  389.        file, then the size of the full uncompressed file, and then the
  390.        binary from offset 0 or specified offset if !Offset was asked.
  391.  
  392.        The last data block  is followed by the  end of file specifier and
  393.        the checksum of the data sent.
  394.  
  395.        End of file specifier format :
  396.  
  397.        <EOT>                    1 byte = 04 hex
  398.        Checksum                 1 byte = 00 to ff hex
  399.  
  400.        The checksum is  equal to  the sum  of all  the data  bytes of the
  401.        transmitted file, modulo 256 (8 bits) and then two's complemented.
  402.  
  403.        The checking of the checksum is very simple :
  404.  
  405.        The sum  of the  datas  from the  file  and the  checksum received
  406.        modulo 256 shall be equal to zero.
  407.  
  408.        In case of a checksum error, the  message or the file is not taken
  409.        to account and the system issues a disconnect request after having
  410.        sent the comment :
  411.  
  412.        *** Erreur checksum
  413.  
  414.        The CRC16 is computed for the full binary file including the length
  415.        of the uncompressed file (4 bytes in top of file). 
  416.        In case of resume, it will be the only mean to be sure that the part 
  417.        of the already received file matches with the new one.
  418.  
  419.        The LZHUF_1 program used with option "e1" generates a binary compressed
  420.        file with the following format :
  421.        CRC16 : 2bytes
  422.        Length: 4 bytes
  423.        Datas : rest of the file
  424.  
  425.        In case of forwarding with a BBS using version 0, only the part from
  426.        offset 2 will be sent
  427.  
  428.        In case of forwarding with a BBS using version 1, the 6 top bytes will
  429.        be always sent, then seek to Offset+6, then send data.
  430.  
  431.        Ascii values of the characters (1 byte) used in the protocole :
  432.  
  433.        <NUL> = 00 hex
  434.        <SOH> = 01 hex
  435.        <STX> = 02 hex
  436.        <EOT> = 04 hex
  437.  
  438.        Comments will be welcome. 
  439.  
  440.        F6FBB @ F6FBB.FMLR.FRA.EU
  441.  
  442.